The present invention relates generally to relationship management systems and, more particularly, to a relationship management system that provides the ability to limit the access of certain contact information to one or more particular folders.
Relationship management systems typically use one or more relational databases to, for example, store data or information pertaining to contacts, which may be individual persons, corporations, etc. The information stored in the database for any particular contact may include, for example, phone numbers, facsimile numbers, post office addresses, electronic-mail (e-mail) addresses, etc. and this information may be used to produce mailing lists and customer lists, to send facsimiles, e-mails, or to store contact information to be retrieved at any desired time. One of the simplest and most common uses of a relationship management system is as a centralized electronic address book that can be used by any number of individuals or groups within, for example, a corporation, a law firm, etc. for any number of reasons, such as keeping track of contact information, making sales calls, sending letters, facsimiles, e-mails, etc.
At least one known relationship management system stores each of the different types of contact information (such as names, post office, street or e-mail addresses, facsimile and phone numbers, company affiliations, titles, etc.) in a database only once and uses folders to provide access to the stored contact information to any number of the users of the relationship management system. Each contact stored within the database may be referenced by any number of folders and each folder typically has access rights that define one or more users of the relationship management system that can access the folder and, thereby, access the contact information associated with the contacts referenced by the folder. There may be different types of folders, such as private or personal folders in which personal contacts, business contacts, etc. are referenced, business folders, group folders set up for specific groups of users, task folders set up for specific tasks, etc. A user may add, change or delete the contact information for any of the contacts within the folders to which the user has access and may add new contacts and associated contact information to the database by adding a new contact to the folder. Each folder may reference more than one contact and each contact may be referenced by more than one folder. Thus, for example, if two users know the same person (a contact), the personal or private folders for each of these users may reference that contact and, thus, each of these users may have access to the contact information associated with that contact, even though the contact information for that contact is stored only once in the database.
The knowledge of which members of a set of users of a relationship management system know a particular person and how the users know that particular person may be helpful in making presentations to that particular person, performing sales activities in which that particular person is involved, conducting research about the particular person or a corporation at which the particular person works, etc. Thus, it can be helpful for one user of a relationship management system to find out which of the other users of that system (who typically work for or are affiliated with the same company or organization) know a particular person or contact. The knowledge of which users of a relationship management system have a relationship of some kind with a particular person or contact stored in the relationship management system is referred to herein as user-contact reference information.
In the past, relationship management systems, while allowing users to access contact information about contacts stored within the database associated with the relationship management system, did not provide any user with the ability to determine, quickly and accurately, which of the other users of the system knew or had a relationship of some kind with a particular contact. In fact, in the past, information about which users of the system knew which contacts had to be manually entered into the database system as a separate list. Because this list of user-contact reference information changes each time a contact is added to a folder or is deleted from a folder within the database, the user-contact reference list had to be constantly updated, which was tedious, time consuming and prone to data entering errors. Furthermore, the updating of the user-contact reference list was typically given a low priority and, thus, the information within this list was frequently out of date. Likewise, these manually created lists did not provide any information on the type of relationship between the contact and the user (or folder) referencing the contact, such as how these people knew each other or how they met, what specific type of relationship exists, such as a business or personal relationship, or the strength of the relationship.
Still further, it is sometimes helpful to limit certain types of, typically, public contact information, such as addresses, phone numbers, etc. to a specific user or folder. For example, a particular contact may tell one user of the relationship management system a home phone number for that contact, but may ask the user to keep that information private. In at least one prior art relationship management system, placing the home phone number in a phone number table within the database makes that number accessible by other users or folders referencing that contact and, thus, the user given the private number cannot place the private number in the proper address or phone number field of the database. Instead, in at least one known system, the user had to place the private phone number (or address) in a xe2x80x9cnotesxe2x80x9d or xe2x80x9cactivityxe2x80x9d field which was created for each different contact referred to by each user""s private folder. These notes fields were stored in a separate table within the database and had a restriction attribute that could be set to make any of the notes fields private to one or more particular folders or globally available to each user or folder. However, this known system did not restrict access to typically public contact information such as addresses and phone numbers stored in address and phone number tables of the database. Still further, this system did not display private phone number or address information (which had to be kept in the notes or activities fields) in the same location on the display screen as phone number or address information available to all of the users, which made it harder to read or use the private phone number and address information in the same manner that the public phone number and address information was read or used.
In another example, certain contact information may be temporary in nature, such as an address, phone number, facsimile number, etc. at which a contact may be reached for the next two months during the conclusion of a deal, a law suit, etc. In this case, it is desirable to only provide this information to users who are working on the deal, law suit, etc., all of which may have access to a particular folder created for that activity. However, again, storing the address and phone number information in the associated contact information tables in one known relationship management system makes the temporary information available to all the users or folders which reference that contact, even users that do not have access to the activity folder for which the information is relevant. This duplicity of information may result in confusion to users of the system who do not know and, generally, do not care, that the contact can be reached, on a temporary basis, at the new address, phone number, etc. In still another case, it may be desirable to restrict certain types of contact information, or all of the contact information for a particular contact to a particular folder to thereby create an information screen which respect to one or more users of the relationship management system.
Still further, some known relationship management systems do not use folders to enable access to contact information. In these systems, certain types of contact information, such as phone number information, can be restricted to individual users. However, these systems do not provide the advantages associated with the use of folders, which makes organization of the contact information more manageable.
Thus, in prior art relationship management systems, there was no way to restrict phone number and address contact information to one folder or user other than using the above-described xe2x80x9cnotesxe2x80x9d or xe2x80x9cactivityxe2x80x9d fields, which displayed the contact information in the context of notes or activities associated with the contact and not in the context of address and phone number information. This, in turn, meant that the same kind of information, such as phone number and address information was being kept in different tables within the database and was being displayed to the user in different contexts. This was undesirable as it could lead to confusion and made the access to private information more difficult.
A relationship management system uses a database to store a visibility attribute for one or more pieces of contact information stored in contact information tables, such as phone number (e.g., phone, facsimile, etc. number) tables or address (e.g., electronic, post office, etc. address) tables. This visibility attribute may be used to indicate which folder(s) can access the contact information stored in the phone number and address tables. For example, the visibility attribute may indicate that the contact information is globally accessible (i.e., accessible to each folder within the relationship management system) or may specify the identity of one or more specific folders through which the particular contact information is visible. Thereafter, only the folders that are listed in the visibility attribute for a specific piece of phone number or address contact information may access the specific piece of contact information and display this information in the proper address or phone number area of a display screen. In this manner, some phone number and address contact information for a particular contact may be folder specific, i.e., accessible or visible from only one folder, while other phone number and address contact information for the same contact may be accessible or visible from all the folders referencing the contact. Still further, private and public phone numbers and addresses may be displayed in the same areas on a display screen to make the phone number and address information more readable and useable.